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RFC 8918 
Invalid TLV Handling in IS-IS 


Abstract 


The key to the extensibility of the Intermediate System to Intermediate System (IS-IS) protocol 
has been the handling of unsupported and/or invalid Type-Length-Value (TLV) tuples. Although 
there are explicit statements in existing specifications, deployment experience has shown that 
there are inconsistencies in the behavior when a TLV that is disallowed in a particular Protocol 
Data Unit (PDU) is received. 


This document discusses such cases and makes the correct behavior explicit in order to ensure 
that interoperability is maximized. 


This document updates RFCs 5305 and 6232. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 


on it may be obtained at https://www.rfc-editor.org/info/rfc8918. 
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This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. Code Components extracted from this document must include 
Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are 
provided without warranty as described in the Simplified BSD License. 
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1. Introduction 


The Intermediate System to Intermediate System (IS-IS) protocol [[SO010589] utilizes Type-Length- 
Value (TLV) encoding for all content in the body of Protocol Data Units (PDUs). New extensions to 
the protocol are supported by defining new TLVs. In order to allow protocol extensions to be 
deployed in a backwards compatible way, an implementation is required to ignore TLVs that it 
does not understand. This behavior is also applied to sub-TLVs [RFC5305], which are contained 
within TLVs. 
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Also essential to the correct operation of the protocol is having the validation of PDUs be 
independent from the validation of the TLVs contained in the PDU. PDUs that are valid must be 
accepted [ISO10589] even if an individual TLV contained within that PDU is not understood or is 
invalid in some way (e.g., incorrect syntax, data value out of range, etc.). 


The set of TLVs (and sub-TLVs) that are allowed in each PDU type is documented in the "TLV 
Codepoints Registry" established by [RFC3563] and updated by [RFC6233] and [RFC7356]. 


This document is intended to clarify some aspects of existing specifications and, thereby, reduce 
the occurrence of non-conformant behavior seen in real-world deployments. Although behaviors 
specified in existing protocol specifications are not changed, the clarifications contained in this 
document serve as updates to [RFC5305] (see Section 3.3) and [RFC6232] (see Section 3.4). 


1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


2. TLV Codepoints Registry 


[RFC3563] established the IANA-managed "IS-IS TLV Codepoints Registry" for recording assigned 
TLV codepoints [TLV_CODEPOINTS]. The initial contents of this registry were based on [RFC3359]. 


The registry includes a set of columns indicating in which PDU types a given TLV is allowed: 


IIH TLV is allowed in Intermediate System to Intermediate System Hello (IIH) PDUs (Point-to- 
point and LAN) 


LSP TLV is allowed in Link State PDUs (LSPs) 


SNP TLV is allowed in Sequence Number PDUs (SNPs) (Partial Sequence Number PDUs 
(PSNPs) and Complete Sequence Number PDUs (CSNPs)) 


Purge TLV is allowed in LSP Purges [RFC6233] 
If "Y" is entered in a column, it means the TLV is allowed in the corresponding PDU type. 


If "N" is entered in a column, it means the TLV is not allowed in the corresponding PDU type. 


3. TLV Acceptance in PDUs 


This section describes the correct behavior when a PDU that contains a TLV that is specified as 
disallowed in the "TLV Codepoints Registry" is received. 
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3.1. Handling of Disallowed TLVs in Received PDUs Other Than LSP Purges 


[ISO10589] defines the behavior required when a PDU is received containing a TLV that is "not 
recognised". It states (see Sections 9.5 - 9.13): 


Any codes in a received PDU that are not recognised shall be ignored. 


This is the model to be followed when a TLV that is disallowed is received. Therefore, TLVs in a 
PDU (other than LSP purges) that are disallowed MUST be ignored and MUST NOT cause the PDU 
itself to be rejected by the receiving IS. 


3.2. Special Handling of Disallowed TLVs in Received LSP Purges 


When purging LSPs, [IS010589] recommends (but does not require) the body of the LSP (i.e., all 
TLVs) be removed before generating the purge. LSP purges that have TLVs in the body are 
accepted, though any TLVs that are present are ignored. 


When cryptographic authentication [RFC5304] was introduced, this looseness when processing 
received purges had to be addressed in order to prevent attackers from being able to initiate a 
purge without having access to the authentication key. Therefore, [RFC5304] imposed strict 
requirements on what TLVs were allowed in a purge (authentication only) and specified that: 


ISes MUST NOT accept purges that contain TLVs other than the authentication TLV. 


This behavior was extended by [RFC6232], which introduced the Purge Originator Identification 
(POD TLV, and [RFC6233], which added the "Purge" column to the "TLV Codepoints Registry" to 
identify all the TLVs that are allowed in purges. 


The behavior specified in [RFC5304] is not backwards compatible with the behavior defined by 
[ISO10589]; therefore, it can only be safely enabled when all nodes support cryptographic 
authentication. Similarly, the extensions defined by [RFC6232] are not compatible with the 
behavior defined in [RFC5304]; therefore, they can only be safely enabled when all nodes 
support the extensions. 


When new protocol behaviors are specified that are not backwards compatible, it is 
RECOMMENDED that implementations provide controls for their enablement. This serves to 
prevent interoperability issues and allow for non-disruptive introduction of the new 
functionality into an existing network. 
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3.3. Applicability to Sub-TLVs 


[RFC5305] introduced sub-TLVs, which are TLV tuples advertised within the body of a parent TLV. 
Registries associated with sub-TLVs are associated with the "TLV Codepoints Registry” and specify 
in which TLVs a given sub-TLV is allowed. Section 2 of [RFC5305] is updated by the following 
sentence: 


As with TLVs, it is required that sub-TLVs that are disallowed MUST be ignored on 
receipt. 


The existing sentence in Section 2 of [RFC5305]: 
Unknown sub-TLVs are to be ignored and skipped upon receipt. 
is replaced by: 


Unknown sub-TLVs MUST be ignored and skipped upon receipt. 


3.4. Correction to POI "TLV Codepoints Registry" Entry 


An error was introduced by [RFC6232] when specifying in which PDUs the POI TLV is allowed. 
Section 3 of [RFC6232] states: 


The POI TLV SHOULD be found in all purges and MUST NOT be found in LSPs with a non- 
zero Remaining Lifetime. 


However, the IANA section of the same document states: 
The additional values for this TLV should be ITH:n, LSP:y, SNP:n, and Purge:y. 


The correct setting for "LSP" is "n". This document updates [RFC6232] by correcting that error. 


This document also updates the previously quoted text from Section 3 of [RFC6232] to be: 


The POI TLV SHOULD be sent in all purges and MUST NOT be sent in LSPs with a non- 
zero Remaining Lifetime. 
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4. TLV Validation and LSP Acceptance 


The correct format of a TLV and its associated sub-TLVs, if applicable, is defined in the document 
(s) that introduces each codepoint. The definition MUST include what action to take when the 
format/content of the TLV does not conform to the specification (e.g., "MUST be ignored on 
receipt"). When making use of the information encoded in a given TLV (or sub-TLV), receiving 
nodes MUST verify that the TLV conforms to the standard definition. This includes cases where 
the length of a TLV/sub-TLV is incorrect and/or cases where the value field does not conform to 
the defined restrictions. 


However, the unit of flooding for the IS-IS Update process is an LSP. The presence of a TLV (or 
sub-TLV) with content that does not conform to the relevant specification MUST NOT cause the 
LSP itself to be rejected. Failure to follow this requirement will result in inconsistent LSP 
Databases on different nodes in the network that will compromise the correct operation of the 
protocol. 


LSP Acceptance rules are specified in [ISO10589]. Acceptance rules for LSP purges are extended 
by [RFC5304] and [RFC5310] and are further extended by [RFC6233]. 


[ISO10589] also specifies the behavior when an LSP is not accepted. This behavior is not altered 
by extensions to the LSP Acceptance rules, i.e., regardless of the reason for the rejection of an 
LSP, the Update process on the receiving router takes the same action. 


5. IANA Considerations 


IANA has added this document as a reference for the "TLV Codepoints Registry". 


IANA has also modified the entry for the Purge Originator Identification TLV in the "TLV 
Codepoints Registry" to be ITH:n, LSP:n, SNP:n, and Purge:y. 


The reference field of the Purge Originator Identification TLV has been updated to point to this 
document. 


6. Security Considerations 


As this document makes no changes to the protocol, there are no new security issues introduced. 


The clarifications discussed in this document are intended to make it less likely that 
implementations will incorrectly process received LSPs, thereby also making it less likely that a 
bad actor could exploit a faulty implementation. 


Security concerns for IS-IS are discussed in [IS010589], [RFC5304], and [RFC5310]. 
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